CPUs (a.k.a. processors or physical processors) default to an assignment in a shared pool if the CPUs are not assigned to a dedicated logical partition workload and are not designated as capacity upgrade processors (i.e., processors that provide capacity on demand). Given that the current art allows for only a single shared pool of CPUs per computer system, conventional logical partitioning provides for only a single shared pool from which to pull CPU micropartitions. In other words, all micropartitions in a single CPU can belong to only one pool. Micropartitioning allows CPUs to be shared via time slicing among multiple operating system instances. This single shared pool constraint limits the configuration options for logical partition allocation so that a system administrator cannot allocate logical partitions based on functionality to keep, for example, test logical partitions from taking processor resources that are best allocated to production. Further, the single shared pool restriction drives up the total cost of ownership (TCO) for software products licensed on a per-CPU basis. For instance, a software product's license is purchased for every CPU in the single shared pool even if the sum of the micropartition allocations for the software is less than the total number of CPUs in the pool. Still further, conflicts arise among multiple organizational departments over the processing resources shared among the departments via the single shared pool. Thus, there exists a need to overcome at least one of the preceding deficiencies and limitations of the related art.